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METHOD AND APPARATUS FOR SEAMLESS MOBILITY BETWEEN 
DIFFERENT ACCESS TECHNOLOGIES 

BACKGROUND OF THE INVENTION 

5 Wireless networking is available to mobile users with higher (wireless local area 

network or WLAN) and lower (wireless wide area network or WW AN) bandwidth 
connections. Mobile terminals are available which could remain active as a user goes 
from areas where higher bandwidth connections are available to areas where lower 
bandwidth connections are available, or vice versa, or even as they dock in wired 

10 docking stations. These mobile terminals can be equipped with adapters for multiple 
types of network connections. However, switching from one network connection to 
another has typically required abandoning and re-establishing a network session. 

Therefore, it is desirable to introduce methods and devices that support moving 
from one wireless network to another seamlessly, maintaining an established network 

15 session. 

SUMMARY OF THE INVENTION 

The present invention includes a method and device to support hand off of a 
session between a mobile terminal and a server, while continuing the session. One 
aspect of the invention is a method involving a first entity having an IP stack and a 
20 second entity having an IP stack. These entities support a hand off from one access 
technology to another, wherein the different access technologies are differentiated by a 
characteristic such as their physical layer. Particular aspects of the present invention are 
described in the claims, specification and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 Figure 1 block diagram of one system in which aspects of the present invention 

can be practiced. 

Figures 2A and 2B are block diagrams of a message and data structure used in a 
demonstration of aspects of the present invention. 

Figure 3 is state transition diagram illustrating aspects of the present invention. 
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Figure 4 is a flow chart for an entity handing off or receiving a hand off of a 
session between a mobile terminal and a server. Figures 5 through 8 are additional flow 
charts related to figure 4. 

Figures 9 through 13 are flow charts for processes running on the mobile 
5 terminal. 

Figures 1 4 and 1 5 are flow charts for processes running on the server. 

Figures 16A and 16B are graphs of demonstrated time for hand off between a 
first access technology and a second access technology, which were a WLAN and a 
WW AN, in this demonstration. 
10 Figures 17A and 17B are graphs of demonstrated packet reception delay during 

a hand off between a first access technology and a second access technology, which 
were a WLAN and a WW AN, in this demonstration. 

DETAILED DESCRIPTION 

The following detailed description is made with reference to the figures. 

15 Preferred embodiments are described to illustrate the present invention, not to limit its 
scope, which is defined by the claims. Those of ordinary skill in the art will recognize a 
variety of equivalent variations on the description that follows. 

Figure 1 is a block diagram of one system in which aspects of the present 
invention can be practiced. A mobile terminal 100 is equipped with adapters for two 

20 different access technologies. These different access technologies may be differentiated 
by their bandwidth. For example, an access technology compliant with a series of 
standards known as 802.1 lx may support 1 1 or 54 Mbps, while a cellular technology 
may support 19,200 or 54,600 bps. Access technologies also may be differentiated by 
their range. Access compliant with a Bluetooth standard may have a short range; 

25 WLAN access compliant with 802. 1 lx may have a medium range; wireless broadband 
access technologies typically provide an extended, line of sight range; cellular 
technologies, which support handoffs among base stations, provide a wide range. A 
further basis for differentiation may be service features, such as available security, cost 
of service, or access to services provided by different vendors that support different 

30 access technologies. One of the access technologies may be a docked access 

technology, when the mobile terminal reaches a wired docking station. The mobile 
terminal may be a laptop computer, a hand-held computer, a Palm-sized computer, a 
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PDA or any other mobile computing platform. The different access technologies can be 
supported by built-in adapters or add-on adapters. Built-in adapters may include 
Bluetooth-compliant RF adapters and laptop docking adapters. Add-on adapters include 
PCMCIA cards manufactured by 3Com, Lucent, Cisco Systems, and others. Either a 
5 pair of adapters or a single combination adapter may be used. 

The principal embodiment described below is cast in terms of a WLAN as a first 
access technology and a WWAN as a second access technology. This description is 
readily extended by one of ordinary skill in the art to a pair of different access 
technologies. Paired access technologies may include 802.1 lx compliant WLAN 

1 0 technology, line-of-sight microwave and RF access technology, unlicensed 2.4 GHz 
technology, Bluetooth technology, docking station technology (hard wired to a 
network,) cellular technology, IS 95b compliant technology, enhanced GSM 
technology, GPRS technology, Metricom technology, WMAN technology, and satellite 
link technology, such as used in some new automobiles. 

15 The embodiment described below also is cast in terms of an access router. More 

generally, an entity having an IP stack can support a mobile terminal handoff, without 
having all the capabilities normally associated with a router. For instance, a wireless 
access point typically receives a MAC frame and converts it into a network protocol 
frame, but the access point does not support router functionality. Upgrading the 

20 wireless access point by adding an IP stack and other resources may allow the wireless 
access point to support handoffs, without a separate router. Similarly, a base station for 
a cellular network may be equipped with an IP stack and resources to support handoffs. 
Bluetooth-compliant adapters may have an integrated IP stack, as many of the Bluetooth 
standards call for transport protocols that rely on IP. 

25 One aspect of the present invention is that connections are managed so as not to 

disrupt a network session, such as a TCP session. This aspect of the invention can be 
understood with reference to the OSI model for implementing protocols in seven layers. 
A typical definition of the model layers is as follows: 
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Function 

Program-to-program communication. 
Manages data representation conversions. For 
example, the presentation layer would be responsible 
for converting from EBCDIC to ASCII. 
Responsible for establishing and maintaining 
communications channels. In practice, this layer is 
often combined with the transport layer. 
Responsible for end-to-end integrity of data 
transmission. . 

Routes data from one. node to another. 
Responsible for physical passing data from one node 
to another. 

Manages putting the data onto the network media 
and taking the data off. 

A TCP or UDP session is conducted at the so-called session and transport layers. One 
aspect of the present invention is that the handoff from a WLAN connection to a 
WW AN connection, for instance, is assisted from the so-called link layer. At the 

5 mobile terminal, this handoff can proceed alternatively as updating the routing table for 
the mobile terminal, updating the default interface of the mobile terminal, or updating 
the default IP address of the mobile terminal. The update may be applied either to a file 
kept the system directory, a location in memory, or a register. Under IPv6, the mobile 
terminal may retain its IP address and update its care-of routing address. In this 

10 invention, the physical layer of network media may be different for different access 

technologies. For example, WWAN technology typically uses GSM or CDMA as radio 
technology whereas WLAN technology uses CS AM/CA spread spectrum radio 
technology. Within the 2.4 GHz band, many different physical layer modes are used. A 
docked access technology provides another distinct physical layer, which may connect 

15 to a host computer or a docking station via a serial, USB or bus-connected technology 
and the host computer or docking station may connect to a network in any practical 
way. Alternatively, a docked access technology may include a network adapter on 
board the mobile terminal, which is plugged into an Ethernet hub or infrastructure. 



Layer Name 

7 application layer 

6 presentation layer 

5 session layer 



4 transport layer 

3 network layer 

2 data link layer 

1 physical layer 
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Returning to figure 1 , the mobile terminal 100 moves from one location to 
another. At the first location, the mobile terminal is in communication with a server 
142 via a first access router 140, connected to the mobile terminal by a first access 
technology such as a WLAN technology. At the second location, the mobile terminal is 
5 in communication with a server 142 via a second access router 150, connected by a 
second access technology, such as a WW AN technology. The communications among 
these components are described below. 

Figure 2 A is a block diagram of a message format used during a demonstration 
of aspects of the present invention. The demonstration was carried out using an 

10 equipment configuration similar to the one depicted in figure 1 . Access routers were 
stimulated on machines using a Linux operating system. Messages controlling the hand 
off process were formatted as ICMP packets, consistent with the Linux handling of 
ICMP packets. The kernel of the Linux operating system was designed only to process 
a few kinds of ICMP packets, including an echo request, time stamp request and address 

15 mask request. Field 201 was set to the distinct packet type "40" to differentiate 
demonstration packets from other ICMP packets. Field 202 contained a code that 
differentiated among control messages. Field 203 was used for an error control symbol. 
In this instance, a checksum was used. Many other error correction schemes would 
work equally well. Field 204 is an identifier, which was not effectively used during the 

20 demonstration. A process ID value was assigned to 204. Field 205 was loaded with a 
sequence number, to investigate packet loss. Data was loaded in Field 206. During part 
of the demonstration, packets 50 bytes long were sent out at 40 millisecond intervals. 

Figure 2B is a block diagram of a receiving buffer structure implemented on the 
access routers during the demonstration. The buffer included a number of data triplets 

25 2 1 0 through 290. The triplets included a pointer to a received IP packet 21 1, a pointer 
to an SRC address for an IP packet, and a link to the data field in the IP packet 

Various input/output processes can be used to handle control commands. Signal 
driven input output for raw sockets can be used to interrupt a main process and receive 
packets. Raw socket programming allows development of a routine which, after 

30 receiving a packet, builds an IP header and sends it to the proper destination, such as 
redirecting packets from a server to mobile terminal. Raw sockets are not bound to use 
TCP/UDP protocols. The kernel of the Linux operating system will pass unrecognized 
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ICMP packets to the user defined raw socket for processing. One option for raw sockets 
is "non-blocking". This option enables development of a program that recognizes 
receipt of incoming packets even when it is sending outgoing packets. The non- 
blocking option can be combined with creation of multiple threads, so that processes for 

5 receiving and sending packets are implemented in separate threads. 

Multithreaded programming also can be suitable for processing of control 
commands and for forwarding of buffer packets. Care needs to be taken with the 
handling of shared data when using multiple threads to implement router processes. 
Figure 3 is a state diagram corresponding to logic segments of one or more 

10 programs running on an access router to support hand off from one access router to 
another of a session between mobile terminal and a host." This state diagram applies 
both to the first access router, which is handing off the session, and the second access 
router that is taking it over. This diagram is useful in understanding the function of 
control messages and a protocol implementing aspects of the present invention. A so- 

1 5 called "initialization" message is sent by the mobile terminal to tell an access router to 
initialize what is needed for a new communication. An "initialization message 
acknowledgment", from the access router that received the initialization message to the 
mobile terminal that sent the initialization message, may be paired with the initialization 
message. A "get data" message was sent by the mobile terminal to the access router 

20 during the demonstration, without requiring an initialization message acknowledgment. 
For demonstration purposes, the get data message was forwarded from the access router 
to the server. The server responded by generating test data. A "stop code" message was 
sent by the mobile terminal to the access router, when the mobile terminal decided to 
initiate a hand off. The access router responded with a "stop message 

25 acknowledgment". A so-called "binding update" message was sent by the mobile 

terminal to an additional or second access router including the address of the first access 
router. This message could, alternatively, be generated for forwarded by the first access 
router after receiving the stop code message, if the first access router were provided 
with the address of the second access router. The second access router processed the 

30 message and forwarded it to the server, which changed its binding update table. The 
second access router responded with a "binding update message acknowledgment". A 
"handshake" message was sent from the second access router to the first access router. 
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The first acce^ uter responded by sending its buffer data packets to the second access 
router, to forw ^ i to be mobile terminal. These buffer data packets were followed by a 
packet over message, which was used to trigger forwarding of packets from the server 
temporarily buffer by the second access router while it was relying packets from the 
5 . first access router to the mobile terminal. Additional messages and acknowledgments, 
combined with time outs, can be defined depending on the reliability of 
communications channels among the access routers and the server. With these 
messages in mind, the states and state transitions in figure 3 can be understood. 

State 301 is a so-called "normal state" in which the access router will redirect 

10 packets in a session between the mobile terminal and the server, from the mobile 
terminal to the server and from the server to the mobile terminal. 

State 302 is a so-called "stop state" in which the access router stops sending 
packets to the server and buffers packets received from the server for later forwarding to 
an additional access router. 

15 State 303 is a so-called "triangle state" in which buffered packets are sent from 

the access router to the additional access router, which, in turn, is responsible for 
forwarding the packets to the mobile terminal. When the access router has sent the last 
buffered packet, it sends a so-called "packet over" code message to the additional access 
router. The process initializes variables and transitions directly to state 304, without 

20 waiting for additional messages or codes. 

State 304 is a so-called "start state" in which the access router is ready to receive 
a new communication or a so-called "binding code update" message. Any 
initializations not previously performed can be performed when the access router first 
enters this state. Otherwise, the router is waiting for directions. 

25 State 305 is a so-called "hand off state" in which the access router may 

temporarily buffer packets received from the server. It relays packets received from an 
additional access router during its triangle state. If it has temporarily buffered packets 
received from the server, it forwards those packets to the mobile terminal upon receipt 
of a "packet over" code message from the additional access router. After the access 

30 router has relayed and transmits packets buffered by the cooperating access routers, it 
transitions directly to state 301, without waiting or additional messages for codes. 
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The messages from the mobile terminal and from the additional access router 
initiate some state transitions. Figure 4 is a summary flowchart, which provides details 
regarding state transitions. The current state value was stored in a global variable. At 
400, the program begins. It first enters a start state 304 and waits for an initialization 

5 message. The demonstration program processed initialization message packets when it 
was in either the start state 304 or the normal state 301. When the program receives an 
initialization message, the program sets the current state to normal state, initializes 401 
the mobile terminal address, using the source address from the incoming control packet, 
and initializes some global variables such as the circular buffer indices. The 

10 demonstration program processed initialization message packets in either the start or 
normal state because the router would be in normal state after a previous 
communications session had finished. Initialization may include creating a thread to 
receive packets 402. Optionally, the program may acknowledge receipt of the 
initialization message. 

15 For demonstration purposes, the get data message also was used. Processing of 

this get data message is not shown in figure 4. The program processed the get data 
message if it was in either a start 304 or normal 301 state. It processed the get data 
message in the normal 301 state because initialization messages were not acknowledged 
and could potentially be lost. Alternatively, initialization messages could be 

20 acknowledged. The program acknowledged receipt of the get data message. If the 
program was in a start state, it treated the get data message as an implied initialization 
message, and performed initialization 401, 402. In the normal state, the program 
redirected the get data message to the server, which processed the get data message as a 
signal to begin sending out test packets. The program running on the access router was 

25 in the normal state after processing and a get data message and proceeded to redirect 
packets from the server to the mobile terminal and vice versa. 

The program processed the stop code message 410 when it was in the normal 
state 301. It set a global variable "stop sending" to true, so that a sending thread would 
know to stop sending out any packets. It acknowledged receipt of the stop code 

30 message to the mobile terminal. The program then transitioned 4 1 1 to the stop state 
302, in which it stopped sending out any packets and waited for a signal from the 
receiving thread, which would indicate receipt of the handshake message. If the 
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program was not in normal state 301 when the stop code message was received, it 
acknowledged the stop code message, but did not act on the message. A special error 
acknowledgment might be used in this situation. 

If the control packet received was not a stop sending message, the program 

5 tested 420 to determine whether it was in hand off state 421 . The details of the 
processing a control packet received while in hand off state are shown in figure 5. 
Similarly, the program tested 430, 440 to determine whether it was in a triangle or 
normal state, if it was not in the hand off state. The processing of control packets 
received while in the triangle 431 and normal 432 states is shown in figures 6 and 7. 

10 Flow returned to 410 after processing a control packet. . 

Figure 5 is the handoff flow chart referred to at 421 . The routine or code 
segment handling the handoff state starts at 521 . It tests 522 whether the number of 
packets in a temporary buffer is greater than zero. If so, it sends out any buffered 
packets 523. Flow proceeds to 524, where the program tests whether the number of 

1 5 buffered packets is zero and a packet over code message has been received. If so, the 
current state is set to normal state and the state transitions. Either way, flow in this 
segment ends 529 and the figure 4 loop is repeated. 

Figure 6 is the triangle flow chart referred to in 43 1 . The routine or code 
segment starts at 63 1 . This routine tests 632 whether the number of packets in a normal 

20 buffer is greater than zero. If so, the program sends out one or more packets from the 
normal buffer 633. Either way, the program tests 634 whether the number of packets in 
the normal buffer is zero. If so, the program initializes global variables, sends out a 
packet over code message to an additional access router, and resets the current state to 
start state 635. Either way, the flow proceeds to end 639 and returns to the loop of 

25 figure 4. 

Figure 7 the normal flowchart referred to in 441 . The routine or code segment 
starts at 741 . This routine tests 742 whether the number of packets in the normal buffer 
is greater than zero. If so, the program sends out one or more packets from the normal 
buffer 743. Either way, flow proceeds to end 749 and returns to the loop of figure 4. 
30 Figure 8 is the receiving thread flow chart. The thread starts at 800. It receives 

a packet from a raw socket 801 . It tests whether the packet is a control or message 
packet 850. If so, it deals with the control packet 851. If not, it tests 860 whether the 
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current state is the hand off state and whether the packet is from the additional access 
router. If both conditions are true, the packet is saved into a temporary buffer 862. 
Otherwise, the packet is saved into a normal buffer 861. Flow loops back to receiving a 
packet 801. 

5 The processing of binding update and handshake messages was not discussed in 

connection with the flow charts above. The binding update is normally received in the 
start state. The binding update message may include the address of another access 
router. The routine or code segment sends out a handshake code to the other access, 
router (again, sometimes called the first access router.) The second access router 

10 transitions to handoff state and waits for the handshake acknowledgement message. It 
gets the address of the server that has been involved in the session with the mobile 
terminal. It communicates to the server a binding update directive. This directive may 
include the address of the access server, the old address of the mobile terminal and a 
new address of the mobile terminal. In IPv6, the address of the mobile terminal may not 

15 change; the directive may include a care-of address for the access router. The directive 
instructs the server to continue its session with the mobile terminal via the access router 
instead of its predecessor, the other or first access router. Alternatively, it may direct 
the server to continue communicating with the mobile terminal line at second access 
technology, different from than the first access technology previously used by the 

20 mobile terminal in the session. The steps of sending the handshake message to the first 
access router and the binding update message to the server can be carried out any either 
order. In a minor variation of this protocol, the mobile terminal could send the binding 
update message via the first access server to the second access server. Then, an 
acknowledgement of the binding update message by the second access server to the first 

25 access server would serve the same function as a handshake message. The second 
access router in the handoff state receives packets from the first access router, 
segregates them in a temporary buffer, and forwards them to the mobile terminal. 
Packets received from the server optionally may be buffered until all of the packets 
from the first access router have been forwarded. This is optional, as some transport 

30 protocols reorder packets received and thus are able to handle an out of order stream 
from the second access router that mixes packets from the first access router and the 
server. The second access router continues to receive and forward packets from the first 
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server until it receives a packet over code message. At that point, it may send the 
mobile terminal packets that it has buffered during relaying of first access router packets 
to the mobile terminal. 

The handshake message is received by the access router first involved in 
5 forwarding session packets between the mobile terminal and the server. The first access 
router normally receives the handshake message when it is in the stop state and is 
buffering packets received from the server. The handshake message may provide the 
address of the second access router to the first router. The first access router responds 
by transitioning to the triangle state and sending any buffered packets from the server to 

10 the second access router for forwarding on to the mobile terminal. The last buffered 
packet sent by the first access server is followed by a packet over code message. Either 
a reliable or unreliable transport protocol, such as TCP or UDP, can be used. A custom 
protocol can be used to minimize overhead. Again, if the binding update message is 
routed through the first access server, any knowledge that by the second access server 

15 may carry out the same function as a handshake message. 

Figures 9 through 13 illustrate aspects of a client process operating on the 
mobile terminal which practices aspects of the present invention. Figure 9 is in 
overview flowchart depicting logic which supplements the client state check and 
processing. This client process interacts with the server, the pair of access routers and a 

20 layer two, link layer process operating on the mobile terminal. The processing logic or 
segment starts at 900. During initialization 910, the client allocates and initializes the 
receive buffer, which is circular buffer. It gathers information on the router IP 
addresses to be used, for both the access router and the additional router access router, 
otherwise referred to as the first entity with an IP stack and the second entity with an IP 

25 stack. It then initializes the signals and the socket. It writes its process ID ("PID"), for 
the link layer process to read, in accordance with inter-process communication 
protocols. It waits for the link layer process to respond with its process ID, which it 
reads and stores for later use. It waits for interface information from the link layer; 
which allows it to determine whether to use the first access technology or the second 

30 access technology at startup. After initialization, the process precedes with a buffer 

processing loop. It tests whether the receive buffer is empty 911. If it is not empty, it • 
processes the data packet 912. For demonstration purposes, the data packets depicted a 
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banner which was displayed on a standard output. If an end of file signal was detected 
913, display ended. Otherwise 9 14, the data packet was displayed on the screen. One 
packet was processed per iteration. If this had been an audio application, the received 
packet would have been piped to an audio player. Generally, an incoming packet in the 

5 data buffer would be appropriately processed. In any case, the flow then proceeds to 
client state check and processing 920. 

Figure tended takes a program trend for receiving packets. The process is signal 
I/O based reception. An incoming packet was processed by routine depicted in figure 
tended, even has another routine was out putting packets. This process or logic segment 

10 starts at 1000. It first test for the error condition of buffer overflow 1001. It In the case 
of an error, it exited with an error 1002. Otherwise, check it validated at the packet was 
properly formed 1003. The case of an error, the routine returned without saving the 
packet 1004. That has, it ignored the packet. A wealth informed packet was tested to 
determine whether a control packet acknowledgment 1005. A control packet 

15 acknowledgment is processed by setting an appropriate flag 1006. Otherwise, for 
demonstration purposes, the packet necessarily was a data packet. It was saved in a 
buffer and the receive time recorded 1007. The routine returned to wear the program 
was interrupted for the signal driven I/O. Other alternatives for I/O implementation 
include multithreaded processes and non-blocking socket implementations. 

20 Figure 1 1 is a flowchart of the main state check and processing logic for the 

client running on the mobile terminal, supported by signal handling depicted in figures 
12 and 13. This process or logic segment starts at 1 100 and implements states 
numbered 0-5. It maintains the states and changes states based on the control packets 
and signals processed. The state controller also maintains time outs and is responsible 

25 for retransmission of lost control signals. If current state equals 1 (as due to a hand off 
signal from the link layer) 1 1 10, a stop signal is sent by the client process and the state 
reset to 2, at 1 1 1 1 . The process then returns 1119. If the current state equals 2 and the 
expected stop acknowledgement signal is received 1 120, the state is reset to 3, at 1 121. 
The process then returns 1 129. If the current state equals 3 and the expected control 

30 signal is received 1 130, a so called "kill if message is sent and the state reset to 4, at 
1131. The process then returns 1 1 40. If the current state equals 5 (as due to an 
interface signal from the link layer) 1 150, the process stands binding update and 
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handoffs messages and the state is reset to 0, at 1 1 5 1 . The process then returns 1159. If 
the state equals 4, at 1 160, the process is waiting for an interface signal from the link 
layer, as depicted in figure 13. In figure 13, an interface signal from the link layer is 
processed by logic, which changes the state from 4 to 5. After the state is changed, the 
5 logic returns to where the process was before the interface signal arrived. Figure 12 
detects processing of a handoff signal from the link layer process. When a handoff 
signal is received 1200, the state is reset to 1 (1201) and processing returns to where it 
was before the handoff signal arrived 1209. 

Figure 14 is a flowchart of the process running on the server for demonstration 

10 purposes, supported by signal handling depicted in figure 15. This process logic starts 
at 1400. Initialization (1401) includes initialization of a receive buffer, creation of 
sockets and initialization of signal values. The process tests whether the receive buffer 
is empty 1402. If it is, the process loops and waits for the receive buffer to contain a 
packet or message for processing. When the buffer contains a packet 1403, the packet 

15 is processed. If the packet is a get data message, used for demonstration purposes, the 
server opens a file 1405 which contains certain data, and sends 50 bytes of data every 
40 milliseconds 1406. If another get data message is in the receive buffer upon 
completion of sending the file 1407, the contents of the file are sent again. Otherwise, 
the flow of control loops to 1402. Figure 15 depicts the processing of a packet received 

20 . signal. The process is triggered at 1 500 by the signal. It first tests for receive buffer 
overflow 1501, and exits with an error 1502 if the buffer overflows. Otherwise, it it 
tests whether the packet is properly formed 1503. If not, the process exits without 
saving the packet 1504, effectively ignoring the packet. It tests whether a well-formed 
packet is a binding update message 1505. If so, the server updates its binding cash can 

25 and exits. The implementation of this update and depends on the version of DP. Under 
IPv4, a new IP address for the mobile terminal is stored, updating the server's routing 
table. Under IPv6, a new care-of address is associated with the mobile terminal. If a 
well-formed packet is not a binding update message 1507, then it is interpreted as a data 
send request and saved in the packet buffer for processing by the loop of figure 14. The 

30 next word the processing of the packet received signal terminates and control returns to 
where the process was interrupted 1509. 
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Figures 16A and 16B depict the time required for hand offs in a series of 20 
trials. The A and B figures, respectively, illustrate measurements made with the mobile 
terminal moving from a WLAN to WWAN environment and vice versa. 

Figures 17A and 17B plot the delay experienced between successive receive 
5 packets during the demonstration. The A and B figures, respectively, illustrate 
measurements made with the mobile terminal moving from a WLAN to WWAN 
environment and vice versa. The actual handoff took place during the period of the 
local longest packet delays. - 

While the preceding examples are cast in terms of a method, devices and 
10 systems employing this method are easily understood. A magnetic memory containing 
a program capable of practicing the claimed method is one such device. A computer 
system having memory loaded with a program practicing the claimed method is another 
such device. 

While the present invention is disclosed by reference to the preferred 
15 embodiments and examples detailed above, it is understood that these examples are 
intended in an illustrative rather than in a limiting sense. It is contemplated that 
modifications and combinations will readily occur to those skilled in the art, which 
modifications and combinations will be within the spirit of the invention and the scope 
of the following claims. 

20 

We claim as follows: 
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CLAIMS 

1. A method of buffering and forwarding packets to support a hand off of a 
session between a mobile terminal and a server, the hand off involving a first entity 
having an IP stack and a second entity having an IP stack, including: 

5 (a) receiving at a first entity having an IP stack, via a first access technology, a first 

message from a mobile terminal to stop sending and begin buffering session 
packets exchanged with a server; 

acknowledging the first message; 

(b) receiving at a second entity having an IP stack, via a second access technology, 
10 the second access technology utilizing a different physical layer than the first 

access technology, a second message from the mobile terminal directing the second 
entity to set up a new route between the mobile terminal and the server via the 
second entity; 

acknowledging the second message; 

15 signaling from the second entity to the first entity to start forwarding the buffered 

packets; 

(c) receiving at the second entity the forwarded buffered packets; 

relaying the forwarded buffered packets to the mobile terminal; 

communicating to the server the new route; and 

20 continuing the session between the mobile terminal and the server via the new 

route. 

2. The method of claim 1, wherein the (c) receiving step and the communicating 
step are carried out in an order as listed. 

3. The method of claim 1, wherein the (c) receiving step and the communicating 
25 step are carried out in an order different than listed. 
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4. The method of claim 1 , wherein the (a) receiving step and the (b) receiving step 
are carried out in an order as listed. 

5 . The method of claim 1 , wherein the (a) receiving step and the (b) receiving step 
are carried out in an order different than listed. 

5 6. The method of claim 1 , wherein the new route is via the second entity. 

7. The method of claim 1 , wherein the new route utilizes the second access 
technology. 

8. The method of claim 1, wherein communicating the new route includes 
communicating a new IP address for the mobile terminal and an IP address for the 

10 second entity. 

9. The method of claim 1 , wherein communicating the new route includes a care- 
of for the mobile terminal. 

10. The method of claim 9, the care-of address is an IP address of the second entity. 

11. The method of claim 1, wherein the first message includes data elements for 
15 message type, message code, sequence number and error detection symbol. 

12. The method of claim 1 1, wherein the error detection symbol is a checksum. 

1 3 . The method of claim 1 , wherein the first message and the second message both 
include data elements for message type, message code, sequence number and error 
detection symbol. 

20 14. The method of claim 13, wherein the error detection symbol is a checksum. 

15. The method of claim 1, wherein the first access technology is compliant with 
any 802.1 lx standard. 

16. The method of claim 1, wherein the first access technology includes using an 
unlicensed 2.4 GHz network. 
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17. The method of claim 1, wherein the first access technology is compliant with 
any Bluetooth standard. 

18. The method of claim 1, wherein the first access technology includes using an 
RF connection compliant with any Bluetooth standard. 

5 1 9. The method of claim 1 , wherein the session is a TCP session. 

7.0. The method of claim 1 , wherein the session is a UDP session. 

_ i . The method of claim 1 , wherein the session is a WAP session. 

22. The method of claim 1 , wherein the session includes a Bluetooth standard 
compliant transport session. 

10 23. The method of claim 1, wherein the connection via the second access 

technology is a PPP connection. 

24. The method of claim 1 , wherein the second access technology is compliant with 
an IS 95b standard. 

25. The method of claim 1, wherein the second access technology is compliant with 
1 5 an enhanced GSM standard. 

26. The method of claim 1, wherein the second access technology is compliant with 
a GPRS standard. 

27. The method of claim 1, wherein the second access technology is compatible 
with access via Metricom. 

20 28. The method of claim 1, wherein the second access technology utilizes a cellular 

telephone network. 

29. The method of claim 1, wherein the second access technology utilizes an 
unlicensed 2.4 GHz network. 



BNSDOCID: <WO 02096132A1 J_> 



WO 02/096132 



PCT/US02/16610 



18 

30. The method of claim 1, wherein the second access technology is made using 
communication between a satellite and the mobile terminal for at least one direction of 
the second access technology connection. 

3 1 . The method of claim 1 , wherein the second access technology is compliant with 
5 any Bluetooth standard. 

32. The method of claim 1, wherein the second access technology includes using an 
RF connection compliant with any Bluetooth standard. 

33. The method of claim 1, further including buffering packets received at the 
second access router from the server until after completion of forwarding the.buffered 

10 packets to the mobile terminal. 

34. A method of buffering and forwarding packets to support a hand off of a 
session between a mobile terminal and a server, the hand off involving a first entity 
having an IP stack and a second entity having an IP stack, including: 

(a) receiving at a first entity having an IP stack, via a first access technology, a first 
15 message from a mobile terminal to stop sending and begin buffering session 

packets exchanged with a server; 

acknowledging the first message; 

(b) receiving at a second entity having an IP stack a second message to set up a 
new route from the mobile terminal to the server via a second access technology, 

20 the second access technology utilizing a different physical layer than the first 

access technology; 

signaling from the second entity to the first entity to start forwarding the buffered 
packets; 

forwarding the buffered packets from the first entity to the second entity and on to 
25 the mobile terminal; 

communicating to the server the new route; and 
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continuing the session between the mobile terminal and the server via the second 
access technology. 

35. The method of claim 34, wherein the forwarding step and the communicating 
step are carried out in an order as listed. 

5 36. The method of claim 34, wherein the forwarding step and the communicating 

step are carried out in an order different than listed. 

37. The method of claim 34, wherein the (a) receiving step and the (b) receiving 
step are carried out in an order as listed. 

38. The method of claim 34, wherein the (a) receiving step and the (b) receiving 
10 step are carried out in an order different than listed. 

39. The method of claim 34, wherein the new route is via the second entity. 

40. The method of claim 34, wherein the new routr utilizes the second access 
technology. 

41. The method of claim 34, wherein communicating the new route includes 
15 communicating a new IP address for the mobile terminal and an IP address for the 

second entity. 

42. The method of claim 34, wherein communicating the new route includes a care- 
of for the mobile terminal. 

43. The method of claim 42, the care-of address is an IP address of the second 
entity. 

44. The method of claim 34, further including buffering packets received at the 
second access router from the server until after completion of forwarding the buffered 
packets to the mobile terminal. 

45. A method of buffering and forwarding packets to support a hand off involving a 
first entity having an IP stack and a second entity having an IP stack, the first entity 
supporting communication with a mobile terminal via a first access technology, the 
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second entity supporting communication with the mobile terminal via a second access 
technology and the mobile terminal engaged in a session with a server via the first 
access technology, the method including: 

receiving at the second entity a message to set up a new route from the mobile 
5 terminal to a server via the second access technology, the second access technology 

utilizing a different physical layer than the first access technology; 

communicating to the server the new route; 

signaling from the second entity to the first entity to forward any buffered packets; 

forwarding the buffered packets from the first entity to the second entity and on to 
10 the mobile terminal; and 

continuing the session between the mobile terminal and the server via the second 
access technology. 

46. The method of claim 45, wherein the (c) receiving step and the communicating 
step are carried out in an order as listed. 

15 47. The method of claim 45, wherein the (c) receiving step and the communicating 

step are carried out in an order different than listed. 

48. The method of claim 45, wherein the (a) receiving step and the (b) receiving 
step are carried out in an order different than listed. 

49. The method of claim 45, wherein the new route is via the second entity. 

20 50. The method of claim 45, wherein the new route utilizes the second access 

technology. 

5 1 . The method of claim 45, wherein communicating the new route includes 
communicating a new IP address for the mobile terminal and an IP address for the 
second entity. 
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52. The method of claim 45, wherein communicating the new route includes a care- 
of for the mobile terminal. 

53. The 'method of claim 52, the care-of address is an IP address of the second 
entity. 

5 54. The method of claim 45, the first message includes data elements for message 

type, message code, sequence number and error detection symbol. 

55. The method of claim 54, wherein the error detection symbol is a checksum. 

56. The method of claim 45, wherein the first message and the second message 
both include data elements for message type, message code, sequence number and error 

10 detection symbol. 

57. The method of claim 56, wherein the error detection symbol is a checksum. 

58. The method of claim 45, wherein the first access tec* jiology is compliant with 
any 802.1 lx standard. 

59. The method of claim 45, wherein the first access technology includes using an 
15 unlicensed 2.4 GHz network. 

60. The method of claim 45, wherein the first access technology is compliant with 
any Bluetooth standard. 

61 . The method of claim 45, wherein the first access technology includes using an 
RF connection compliant with any Bluetooth standard. 

20 62. The method of claim 45, wherein the session is a TCP session. 

63. The method of claim 45, wherein the session is a UDP session. 

64. The method of claim 45, wherein the session is a WAP session. 

65. The method of claim 45, wherein the session includes a Bluetooth standard 
compliant transport session. 
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66. The method of claim 45, wherein the connection via the second access 
technology is a PPP connection. 

67. The method of claim 45, wherein the second access technology is compliant 
with an IS 95b standard. 

5 68. The method of claim 45, wherein the second access technology is compliant 

with an enhanced GSM standard. 

69. The method of claim 45, wherein the second access technology is compliant 
with a GPRS standard. 

70. The method of claim 45, wherein the second access technology is compatible 
10 with access via Metricom. 

71 . The method of claim 45, wherein the second access technology utilizes a 
cellular telephone network. 

72. The method of claim 45, wherein the second access technology utilizes an 
unlicensed 2.4 GHz network. 

15 73. The method of claim 45, wherein the second access technology is made using 

communication between a satellite and the mobile terminal for at least one direction of 
the second access technology connection. 

74. The method of claim 45, wherein the second access technology is compliant 
with any Bluetooth standard. 

20 75. The method of claim 45, wherein the second access technology includes using 

an RF connection compliant with any Bluetooth standard. 

76. The method of claim 45, further including buffering packets received at the 
second access router from the server until after completion of forwarding the buffered 
packets to the mobile terminal. 
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77. A second entity having an IP stack adapted to accepting from a first entity 
having an IP stack a hand off between a first access technology and a second access 
technology of a session between a mobile terminal and a server, including: 

a processor, having memory and resources, including an IP stack; 

5 one or more communication ports, coupled with the processor, in communication 

with the first entity and in communication with the mobile terminal; 

program storage memory, coupled with the processor, containing one or more 
programs adapted to: 

(a) receiving at a first entity having an IP stack, via a first access technology, a 
first message from a mobile terminal to stop sending and begin buffering 
session packets exchanged with a server; 

acknowledging the first message; 

(b) receiving at a second entity having an IP stack, via a second access 
technology, the second access technology utilizing a different physical layer 
than the first access technology, a second message from the mobile terminal 
directing the second entity to set up a new route between the mobile terminal 
and the server via the second entity; 

acknowledging the second ihessage; 

signaling from the second entity to the first entity to start forwarding the 
buffered packets; 

(c) receiving at the second entity the forwarded buffered packets; 
relaying the forwarded buffered packets to the mobile terminal; 
communicating to the server the new route; and 

continuing the session between the mobile terminal and the server via the new 
route. 



15 



20 
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78. A second entity having an IP stack adapted to accepting from a first entity 
having an IP stack a hand off between a first access technology and a second access 
technology of a session between a mobile terminal and a server, including: 

a processor, having memory and resources, including an IP stack; 

5 one or more communication ports, coupled with the processor, in communication 

with the first entity and in communication with the mobile terminal; 

program storage memory, coupled with the processor, containing one or more 
programs adapted to: 

(a) receiving at a first entity having an IP stack a first access technology a first 
10 message from a mobile terminal to stop sending and begin buffering session 

packets exchanged with a server; 

acknowledging the first message; 

(b) receiving at a second entity having an IP stack a second message to set up a 
route from the mobile terminal to the server via a second access technology, 

15 the second access technology utilizing a different physical layer than the first 

access technology; 

signaling from the second entity to the first entity to start forwarding the 
buffered packets; 

forwarding the buffered packets from the first entity to the second entity and 
20 on to the mobile terminal; 

communicating to the server a care-of address for routing via the second access 
technology; and 

continuing the session between the mobile terminal and the server via the 
second access technology. 
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79. A second entity having an IP stack adapted to accepting from a first entity 
having an IP stack a hand off between a first access technology and a second access 
technology of a session between a mobile terminal and a server, including: 

a processor, having memory and resources, including an IP stack; 

. 5 one or more communication ports, coupled with the processor, in communication 

with the first entity and in communication with the mobile terminal; 

program storage memory, coupled with the processor, containing one or more 
programs adapted to: 

receiving at the second entity a message to set up a new route from the mobile 
10 terminal to the server via the second access technology, the second access 

y technology utilizing a different physical layer than the first access technology; 

communicating to the server the new route; 

signaling from the second entity to the first entity to forward any buffered 
packets; 

15 forwarding the buffered packets from the first entity to the second entity and 

on to the mobile terminal; and 

continuing the session between the mobile terminal and the server via the 
second access technology. 

80. An entity having an IP stack, adapted to cooperating with an additional entity 
20 having an IP stack in a hand off of a session between a mobile terminal and a server, the 

entity including: 

a processor, having memory and resources, the resources including an IP stack; 

one or more communication ports, coupled with the processor and in 
communication with the mobile terminal, the server and the additional entity; 
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program storage memory, coupled with the processor, containing one or more 
programs, including logic segments to 

(1) forward packets in the session between the mobile terminal and the server; 

(2) stop forwarding the packets in the session and buffer the packets received 
from the server; 

(3) forward the buffered packets to the additional entity; 

(4) wait for a message to take over the session between the mobile terminal 
and the server; and 

(5) communicate an address of the entity to the server with a binding update 
directive; signal the additional entity to begin forwarding the buffered 
packets; and forward the buffered packets received from the additional 
entity to the mobile terminal; 

wherein the one or more programs transition among logic segments, including: 

transitioning from logic segment (1) to logic segment (2) upon receiving a first 
message type from the mobile terminal; 

transitioning from logic segment (2) to logic segment (3) upon receiving a 
second message type from the additional entity; 

transitioning from logic segment (3) to logic segment (4) upon completing the 
forwrding of buffered packets to the additional entity; 

transitioning from logic segment (4) to logic segment (1) upon receiving an 
initial message type from the mobile terminal; 

transitioning from logic segment (4) to logic segment (5) upon receiving a third 
message type from the additional entity; 
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transitioning from logic segment (5) to logic segment (1) upon receiving a 
fourth message type from the additional entity indicating completion of 
forwarding of the buffered packets. 

81. The device of claim 80, wherein state (4) is treated as two states (4a) and (4b); 
5 the transition to state (1) proceeds from state (4a); and the transition to state (5) 

proceeds from state (4b). 

82. The device of claim 80, wherein logic segment (5) carries out actions in an 
order as listed. 

83. The device of claim 80, wherein logic segment (5) carries out actions in an 
10 order different than listed. 

84. The device of claim 80, wherein: 

logic segment (5) further includes temporarily buffering any packets received from 
the server while forwarding the buffered packets received from the additional entity 
to the mobile terminal; and 

15 transitioning from logic segment (5) to logic segment (1 ) further includes 

forwarding to the mobile terminal the temporarily buffered packets received from 
. the server upon receiving the fourth message type from the additional entity. 
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